home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 16103 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.6 KB
  1. Path: keats.ugrad.cs.ubc.ca!not-for-mail
  2. From: c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku)
  3. Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu
  4. Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)
  5. Date: 9 Apr 1996 08:40:02 -0700
  6. Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
  7. Message-ID: <4ke0ciINNgg8@keats.ugrad.cs.ubc.ca>
  8. References: <JSA.96Feb16135027@organon.com> <dewar.828987544@schonberg> <4kcein$mev@solutions.solon.com> <dewar.829054330@schonberg>
  9. NNTP-Posting-Host: keats.ugrad.cs.ubc.ca
  10.  
  11. In article <dewar.829054330@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote:
  12. >I said
  13. >
  14. >>>Can you quote the relevant standard. No description of read I ever saw
  15. >>>was detailed or precise enough to say what the requirements on the caller
  16. >>>are.
  17. >
  18. >Peter said
  19. >
  20. >>If it is not specified, it's undefined.  At least, that's how C does it;
  21. >>no guarantees for POSIX.
  22. >
  23. >Robert replies
  24. >
  25. >OK, "it" here is any specification of how long the buffer should be. So
  26. >Peter considers it undefined, in which case *any* call to read is
  27. >undefined. Actually I completely agree, if the spec of a routine is
  28. >incomplete or imprecise, the routine cannot be called without generating
  29. >undefined behavior.
  30. >
  31. >But in the absence of Kazimir to tell us the "unwritten" rules, isn't it
  32. >just possible that this *might* lead to portability problems :-) Of course
  33. >by Peter's rules, we can't call read at all :-)
  34.  
  35. No, the _rational_ rules. I slipped up in my mention of ``unwritten rules''
  36. because in this case they happen to coincide with the rational ``Bayesian''
  37. choice. In other cases, as in the case of select(), they may not.
  38.  
  39. I did not mean to imply that I would not falsely advertize a buffer to read()
  40. simply because I feel that there is an unwritten rule among a community of
  41. programmers which prohibits this. I would not do this due to a reasoning
  42. process, which may come up with an answer that is different from the concensus.
  43. A later clarification in the standard, and subsequent compliance by all
  44. implementations, may render my assumption paranoid, but until then the rational
  45. choice gives a fighting chance that the program will work and be portable.
  46.  
  47. I recognize that there are cases where such reasoning may fail to achieve a
  48. resolution. In the Pascal table, you may have a "you are screwed" in each row
  49. and column, in which case you must consider additional alternatives.
  50.  
  51. >Peter do you have SPEC1170, I assume you must have a copy, so can you
  52. >see there if the spec is any more illuminating?
  53.  
  54. That would be helpful.
  55.  
  56. ---
  57.  
  58. A good friend of mine says: you can spot a programmer in a one way street---he
  59. is the one who looks both ways before crossing.
  60. -- 
  61.  
  62.